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ABSTRACT 


Space  Plug-and-Play  Architecture  (SPA),  as  defined  by  the  SPA  subject  matter  experts,  is 
“a  spacecraft  development  architecture  that  includes  technology  and  standards  developed 
to  facilitate  simplified  design,  assembly,  and  test  of  spacecraft  systems  using  modular 
components  to  reduce  spacecraft  development  cost  and  schedule.”  There  is  a  need  to 
assess  the  maturity  of  SPA  to  determine  its  benefits  and  return  on  investment.  SPA,  being 
a  system  and  a  combination  of  technology  and  standards,  poses  challenges  for  the 
maturity  assessment.  In  this  thesis,  the  author  presents  the  methodologies  to  assess  the 
maturity  of  SPA,  using  the  existing  Technology  Readiness  Level  (TRL)  process  for 
technology  and  developing  new  process  for  the  standards.  The  TRL  process  is  applied  to 
the  technology  components  and  the  SPA  system.  The  proposed  process  for  assessing  the 
maturity  of  the  product  development  standards  is  similar  to  the  TRL  process,  but  tailored 
for  applicability  to  standards.  The  methodology  for  assessing  the  maturity  of  SPA 
standards  is  based  on  the  premises  of  “what  was  done  and  under  what  conditions.” 
Applying  these  methodologies  to  assess  the  maturity  of  SPA  gives  a  complete  picture  of 
the  status  of  SPA  development,  which  is  used  to  estimate  the  cost  to  reach  full  maturity 
with  more  accuracy. 
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EXECUTIVE  SUMMARY 


Space  Plug-and-Play  Architecture  (SPA)  introduces  a  new  paradigm  for  building 
spacecraft  based  on  a  familiar  plug-and-play  concept  in  the  computing  industry.  The 
purpose  of  this  thesis  is  to  assess  the  maturity  of  the  current  Space  Plug-and-Play 
Architecture  development  in  order  to  detennine  its  benefits  and  the  future  return  on 
investment. 

SPA  development  began  in  2004  at  the  Air  Force  Research  Laboratory,  Kirtland 
Air  Force  Base,  New  Mexico.  The  approach  involves  representing  a  complex  system  as  a 
self-organizing  network  of  composable  and  discoverable  and  self-describing  components 
with  standard  interfaces,  rather  than  with  the  traditional  point-to-point  or  connections.  In 
a  SPA  system,  the  components  have  build-in  software  code  that  describes  their  functions 
and  characteristics  and  are  fully  interchangeable.  Once  the  components  are  connected, 
they  form  the  SPA  network.  The  SPA  system  automatically  organizes  them  by  the  type  of 
data  they  provide  and/or  require  from  the  network.  The  SPA  system  mechanical  and 
electrical  interface  is  standardized,  thus  all  the  connection  points  are  the  same,  making  it 
very  composable.  The  SPA  network  can  be  formed  with  as  many  components  as  needed. 
As  defined  by  the  SPA  developers,  SPA  is  “a  spacecraft  development  architecture  that 
includes  technology  and  standards  developed  to  facilitate  simplified  design,  assembly, 
and  test  of  spacecraft  systems  using  modular  components  to  reduce  spacecraft 
development  cost  and  schedule.” 

Three  key  processes  for  maturity  assessment — the  Technology  Readiness  Level 
(TRL)  process,  the  Integration  Readiness  Level  (IRL)  process,  and  the  System  Readiness 
Level  (SRL)  process — are  reviewed  and  found  to  be  insufficient  for  completely  assessing 
SPA  maturity,  as  SPA  is  not  simply  a  single  technology,  but  a  set  of  concepts  (hardware, 
software,  and  protocols)  forming  an  architecture  that  includes  both  technology  and 
standards.  A  new  maturity  assessment  approach  is  thus  needed  for  SPA.  This  new 
approach  involves  assessment  of  both  technology  and  standards. 
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For  the  technology  assessment,  the  TRL  process,  which  is  sanctioned  by  the 
Department  of  Defense,  was  used.  The  challenge  with  using  the  TRL  assessment  is  the 
fact  that  it  is  designed  to  assess  the  technology  at  the  component  level  rather  than  at  the 
system  level.  SPA  is  a  network  of  components,  which  implies  that  the  network  itself  is 
the  system  or  subsystem.  The  TRL  process  can  be  used  to  assess  the  maturity  of  the 
individual  hardware  and  software  components,  but  not  traditionally  for  a  network  or 
system.  To  overcome  this  problem,  the  network  had  to  be  thought  of  as  a  component,  a 
“super-component”  that  is  made  up  of  components  and  parameters  associate  with 
component  interfaces.  However,  because  the  network  itself  is  more  than  the  sum  of 
components  and  their  interfaces,  it  becomes  an  entity  with  its  own  characteristics  that 
differ  from  the  sum  of  all  the  characteristics  of  the  components  and  interfaces.  By  adding 
dimensions  more  specific  to  the  network  as  factors  in  the  evaluation,  the  TRL  process  can 
be  and  was  applied  to  assess  the  SPA  network  maturity.  Unlike  the  technology 
assessment,  the  standards  maturity  assessment  is  not  guided  by  or  based  on  any  known 
guidance  or,  leaving  the  interpretation  of  maturity  opens  to  judgment.  The  standards 
maturity  assessment  is  the  assessment  of  how  mature  the  standards  are — how  far  along 
they  are  in  the  development  cycle  and  whether  they  are  being  accepted  and  used.  In  this 
work,  a  new  standards  maturity  assessment  methodology  is  developed,  which  is  based  on 
the  TRL  process’s  premises  of  “what  was  done  and  under  what  condition.”  The  two 
factors  used  in  the  standards  maturity  assessment  are  the  state  of  the  standard 
development  and  acceptance  of  the  standard  by  the  community.  Rather  than  using  a 
numerical  set,  the  standards  maturity  levels  are  a  set  of  four  descriptive  levels  with 
supporting  information  and  definitions.  The  four  levels  are  defined  as:  (1)  immature, 
(2)  sufficient,  (3)  mature,  and  (4)  fully  mature.  In  some  cases  such  as  USB  and  Wireless 
adapter  specifications,  standards  are  based  on  the  documentation  of  the  agreed-upon 
specifications,  and  the  numerical  values,  therefore,  have  no  added  benefit.  The  standards 
are  based  on  consensus.  The  maturity  assessment  is  not. 

In  this  new  approach  to  assessing  SPA  maturity,  a  SPA  rating  of  “4  (Mature)” 
means  its  corresponding  TRL  rating  is  “4”  and  its  standards  maturity  rating  is  “Mature.” 
It  is  not  necessary  to  combine  the  TRL  and  standards  maturity  ratings  into  a  single  rating, 


as  the  main  goal  of  the  SPA  assessment  is  to  identify  future  activities  needed  to  estimate 
the  remaining  cost  to  reach  a  fully  mature  SPA.  As  the  estimated  cost  for  bringing  a 
system  to  “fully  mature”  standards  is  detennined  by  what  else  is  left  to  complete  the 
standards  based  on  the  current  assessment,  the  cost  estimate  for  the  fully  mature  SPA  is 
determined  by  what  else  is  left  to  complete  based  on  the  current  maturity  of  the  various 
SPA  components  and  network. 

As  a  final  thought,  an  approach  to  combine  two  different  sets  of  maturity 
assessment  is  presented  for  completeness.  This  approach  utilizes  a  method  similar  to  the 
risk  assessment  matrix,  where  the  two  dimensions  of  the  matrix  are  levels  of  likelihood  of 
occurrence  and  consequence  if  it  occurs.  The  traditional  risk  matrix  assessment  has 
5  levels  for  likelihood  and  5  levels  for  consequence,  and  forms  a  5  by  5  square  matrix. 
Each  square  is  color-coded  for  low,  medium,  and  high  risk,  starting  from  lower  left 
comer  to  the  upper  right  corner.  This  method  can  be  applied  to  combine  the  two  different 
sets  of  rating  for  the  maturity  level  of  SPA  and  is  a  subject  of  future  research. 
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I.  INTRODUCTION 


“Plug-and-play”  is  not  a  new  concept.  It  is  best  known  in  the  computing  industry 
with  the  advent  of  the  Universal  Serial  Bus  (USB).  The  Air  Force  Research  Laboratory 
(AFRL)  has  been  developing  technology  to  bring  the  plug-and-play  (PnP)  concept  to 
building  spacecraft,  which  can  result  in  lower  cost  and  shorter  schedules  for  spacecraft 
builds.  With  plug-and-play,  a  spacecraft  manufacturer  does  not  need  to  develop  custom 
interfaces  and  software  codes  to  integrate  and  test  spacecraft  components  and 
subsystems,  saving  time  and  cost  for  integration.  This  thesis  does  not  discuss  the  benefit 
or  debate  the  merits  of  the  Space  Plug-and-Play  Architecture  (SPA),  but,  instead,  focuses 
on  assessing  the  maturity  of  SPA  based  on  a  snapshot  of  the  SPA  development  at  the  time 
of  this  research,  September  2011. 

A.  BACKGROUND 

USB  has  brought  true  plug-and-play  to  the  computing  industry,  allowing  even  the 
unskilled  individuals  to  add  peripherals  to  personal  computers  without  the  need  to 
understand  all  the  inner  workings  of  the  computer  system,  its  software,  hardware,  and 
protocols.  In  creating  a  PnP  approach  for  space  applications,  a  similar  model  was  sought. 
The  model  sought  economies  in  meeting  space  mission  needs  rapidly  by  allowing 
spacecraft  to  be  rapidly  assembled  and  tested,  reducing  cost  and  shortening  the  time 
required  to  put  a  spacecraft  in  orbit.  The  SPA  project  began  development  in  2004  at  the 
Air  Force  Research  Laboratory  (AFRL)  at  Kirtland  AFB,  NM.  Over  the  years,  the  Space 
Vehicles  Directorate  at  Kirtland  AFB  has  invested  between  $  1 5-$60M 1  to  mature  the 
SPA  concept  and  technology  (AFRL,  2011).  The  Directorate  considered  the  project  to 
beat  a  crossroad  in  late  2010,  following  an  organizational  research  portfolio  review  by  the 
Air  Force’s  Science  Advisory  Board  (SAB).  For  example,  was  SPA  sufficiently  mature 
for  a  shift  in  emphasis,  from  research  to  transition?  If  not  mature,  would  it  make  sense  to 
invest  more  to  bring  the  work  to  a  suitable  level  of  maturity?  In  the  traditional  model  of 


1  Exact  estimation  is  complicated,  due  to  the  mixture  of  concepts  in  research  projects  in  which  a 
number  of  ideas  are  being  studied  together  within  particular  projects. 
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laboratories,  technologies  are  germinated,  advanced,  matured,  and  transitioned,  with  the 
latter  state  denoting  a  period  in  which  the  laboratories  perform  a  “hand-off’  to  other 
groups  for  insertion  into  fielded  products.  As  part  of  the  consideration  for  research  into  a 
particular  technology,  it  is  typical  to  stop  pursuit  of  concepts  whose  maturation  requires 
investments  so  large  as  to  render  the  benefits  impractical,  especially  with  the  risks 
involved.  For  SPA,  this  concern  had  also  been  expressed.  A  SPA  Strategic  Study  team 
was  formed  to  provide  answers  to  those  questions  to  a  SPA  Collaboration  Review  Team. 
The  SPA  maturity  assessment  in  this  thesis  is  a  critical  piece  to  be  used  by  the  SPA 
Strategic  Study  team  in  detennining  the  current  state  of  SPA  development. 

As  SPA  is  more  than  just  a  single  point  technology,  the  process  to  assessing  the 
maturity  level  of  SPA  is  complex.  Such  complexity  is  not  conducive  to  approaches 
defined  in  the  existing  DoD  Technology  Readiness  Assessment  (TRA)  Deskbook 
(DODb,  2009).  Furthennore,  the  TRA  Deskbook  approach  provides  little  guidance  for 
assessing  the  maturity  of  standards.  In  SPA,  a  set  of  standards  were  being  developed  in 
parallel  with  the  underlying  technologies.  These  deficiencies  suggested  a  need  for  a  new 
approach,  in  which  the  maturity  for  more  complex  technology  developments  can  be 
estimated,  including  developments  that  involve  standards.  Such  an  approach,  combining 
the  Technology  Readiness  Level  (TRL)  assessment  with  the  standards  assessment,  would 
provide  a  needed  tool  to  assess  the  status  of  the  SPA  project  at  its  given  stage  of 
development. 

B.  PURPOSE 

The  purpose  of  this  thesis  is  to  identify  an  approach  to  assessing  the  maturity  of 
SPA  that  accommodates  the  different  parts  of  SPA,  to  include  a  body  of  standards 
associated  with  the  development. 

C.  RESEARCH  QUESTIONS 

The  questions  to  be  answered  in  this  thesis  are: 

1 .  How  might  a  SPA  maturity  level  be  assessed? 

2.  What  is  the  maturity  level  of  the  SPA? 
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D.  BENEFITS  OF  STUDY 

This  research  is  used  to  support  the  funding  decision  for  continuation  of  the  Space 
Plug-and-Play  Architecture  development  at  the  Air  Force  Research  Laboratory.  The 
AFRL  at  Kirtland  AFB  conducted  a  strategic  analysis  on  SPA  and  held  a  SPA 
Collaboration  Review  in  September  2011.  A  part  of  that  analysis  was  the  maturity 
assessment  of  SPA.  In  addition,  the  methodology  introduced  in  this  thesis  may  facilitate 
future  assessment  of  other  systems  architecture  development. 

E.  SCOPE  AND  METHODOLOGY 

The  thesis  focuses  on  the  development  of  an  approach  to  assessing  the  maturity  of 
the  SPA  technology  and  standards  utilizing  the  following  approaches: 

1 .  Review  SPA  documentation  and  the  SPA  standards 

2.  Review  TRA  Deskbook  and  other  maturity  assessment  methodologies 

3.  Interview  SPA  subject  matter  experts  (SMEs) 

4.  Assess  the  current  SPA  technology  maturity  using  TRA  Deskbook 

5.  Develop  a  methodology  to  assess  the  maturity  of  standards 

6.  Assess  the  maturity  of  the  current  SPA  standards 

7.  Validate  assessments  with  SPA  SMEs 
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II.  LITERATURE  REVIEW 


A.  SPACE  PLUG-AND-PLAY  ARCHITECTURE  DESCRIPTION 

Space  Plug-and-Play  architecture  (SPA)  is  a  system  architecture  that  defines  a 
new  concept  of  building  spacecraft.  The  SPA  concept  involves  a  variety  of  technologies 
(hardware,  software,  and  protocols)  and  a  set  of  standards  designed  to  permit  the  scale  of 
implementation  sufficient  to  drive  an  industry.  Unlike  assessment  of  the  maturity  a  single 
technology,  such  as  a  computer  memory  chip,  assessment  of  the  maturity  of  SPA,  which 
involves  many  technologies,  is  difficult  and  challenging.  Appreciating  the  difficulty  in 
assessing  the  SPA  maturity  necessitates  an  understanding  of  the  concept  of  SPA,  which  is 
described  in  this  chapter. 

SPA  has  been  connected  with  the  pursuit  of  a  “six-day  spacecraft,”  an  idea 
originating  from  the  notion  of  “responsive  space,”  to  complement  previously  discussed 
ideas  of  responsive  spacelift.  The  requirement  for  rapid  response  for  space  became 
formalized  when  the  Department  of  Defense’s  Operationally  Responsive  Space  (ORS) 
was  formed  to  rapidly  build  and  launch  spacecraft  to  meet  operational  needs  (AFRL, 
2011).  In  2004,  AFRL  began  to  explore  a  range  of  technology  concepts  that  could 
dramatically  accelerate  the  pace  at  which  space  systems  could  be  created.  One  of  the 
explored  technology  concepts  was  a  “plug-and-play”  concept,  similar  to  the  concept 
found  in  a  personal  computer.  The  primary  focus  at  the  time  was  on  the  spacecraft 
avionics,  which  include  the  navigation  and  attitude  detennination  and  control  system 
(ADCS).  Thus  SPA  was  originally  known  as  Space  Plug-and-Play  Avionics.  As  the  SPA 
program  progressed,  it  became  evident  that  SPA  is  more  than  just  the  spacecraft  avionics. 
The  architecture  has  impact  on  the  whole  spacecraft  bus  (AFRL,  2011).  The  plug-and- 
play  concept,  as  it  stands,  has  now  been  extended  to  the  whole  spacecraft. 

1.  Definition  of  SPA 

One  definition  of  SPA  as  agreed  upon  by  the  SPA  subject  matter  experts  is  as 
follows:  “Space  Plug-and-Play  Architecture  is  a  spacecraft  development  architecture 
that  includes  technology  and  standards  developed  to  facilitate  simplified  design, 
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assembly,  and  test  of  spacecraft  systems  using  modular  components  to  reduce  spacecraft 
development  cost  and  schedule.  SPA  is  composed  of  standardized  interfaces,  a  standard 
network,  and  a  common  message  fonnat  that  automatically  identifies  and  configures.” 
To  better  explain  it,  SPA  is  the  standard  network  design  that  includes  common  message 
format  and  data-centric  architecture,  where  focus  is  on  the  data  and  not  the  physical 
structure  supporting  the  data  generation  and  movement.  It  is  also  a  standard  modular 
architecture  with  standard  interface,  self-identifying  and  self-configuring  components 
(Lyke  &  Peck,  2011).  When  a  component  is  plugged  into  the  system,  it  will  identify  and 
configure  itself  to  meet  the  needs  of  the  system. 

In  brief,  a  SPA  system  is  a  system  that  meets  the  guidelines  described  in  the  SPA 
standards.  The  SPA  system  can  be  thought  of  as  a  set  of  building  blocks  that  can  be 
arranged  into  a  seemingly  infinite  number  of  configurations.  The  arrangements  are  done 
by  connecting  each  block  with  a  cable.  Since  the  interfaces  are  standard,  there  are  no 
ambiguities  as  to  a  connection,  and  many  “legal”  connections  are  possible  to  achieve  the 
same  overall  function.  An  overall  arrangement  of  components  forms  a  network,  and  the 
network  is  self-organizing  (this  notion  is  captured  in  USB,  as  it  does  not  matter  which 
port  one  plugs  the  USB  device  into).  Beyond  this  composability  is  the  notion  that 
components  intelligently  negotiate  their  roles  within  a  system.  They  are  self-descriptive, 
using  embedded  XML-based  electronic  datasheets,  which  can  be  queried  and  uploaded 
into  an  overall  system  formed  by  several  of  these  components.  This  process,  sometimes 
referred  to  as  “discover  and  join,”  is  an  introspective  mechanism  in  which  the  pieces  are 
discovered  in  both  hardware  and  software  and  linked  within  an  application  framework 
(software).  When  all  the  correct  pieces  are  assembled,  the  system  can  ostensibly  be 
considered  “complete.”  The  plug-and-play  concept  at  this  level  is  abstract,  and  in 
principle  it  could  apply  to  any  system,  regardless  of  scale  and  type.  SPA  was  connected 
to  space  systems,  owing  to  its  research  origins  at  AFRL  in  the  study  of  the  responsive 
space  problem. 
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2. 


The  Architecture 


Terms  such  as  “architecture”  and  “system”  are  overloaded,  having  many  possible 
meanings  that  must  be  made  concise  by  context.  While  at  one  level  a  spacecraft  is 
considered  a  system,  it  is  but  a  component  of  a  larger  system  necessary  in  the 
implementation  of  a  space  mission.  In  this  context,  a  complete  space  system  includes  the 
ground  control,  launch,  spacecraft  systems,  and  users.  A  typical  spacecraft  life  cycle 
process  includes  designing,  building,  launching,  operating  and  sustaining,  and  disposing 
of  the  spacecraft.  SPA,  as  originally  conceived,  is  not  intended  to  affect  spacecraft 
mission  operations  or  end  of  life.  The  SPA  architecture  “sits  on  top”  of  an  existing  space 
architecture,  which  means  that  launch  systems  and  ground  systems  are  not  affected  by 
SPA.  SPA  has  impact  on  the  internal  spacecraft  systems  and  during  the  spacecraft  design 
and  build  phases.  The  spacecraft  external  interfaces  to  launch  and  ground  systems  are  left 
unchanged  (AIAAa,  2011). 

A  typical  spacecraft  is  made  up  of  two  main  subsystems:  the  bus  and  the  payload. 
As  the  name  implies,  the  “bus”  is  a  conveyance  (for  the  payload).  It  handles  all  the  basic, 
necessary  functions  to  keep  the  passenger,  its  “payload,”  focused  on  completing  its 
mission.  Some  examples  of  the  payload  include  the  camera  on  a  reconnaissance 
spacecraft  or  a  suite  of  transmitting  and  receiving  antennas,  with  its  own  system 
processor  on  a  communication  spacecraft.  The  bus  is  further  divided  into  different 
subsystems  that  provide  different  functions  to  the  spacecraft  such  as  power  management, 
navigation,  attitude  determination  and  control  system  (ACDS),  thermal  handling  and  so 
on.  The  subsystems  are  further  broken  down  into  different  parts  and  components.  The 
ACDS,  for  example,  consists  of  the  magnetometer,  reaction  wheel  assembly  and  other 
parts.  In  a  traditional  spacecraft  development,  the  bus  and  the  payload  are  built  separately 
and  then  mated  together  during  the  space  vehicle’s  assembly,  integration,  and  test  (AIT) 
phase.  Since  the  current  SPA  development  primarily  focuses  on  the  bus,  this  thesis 
discusses  only  the  topics  that  are  related  to  the  bus. 

For  a  traditional  spacecraft  build,  related  bus  components  connect  directly  to  each 
other — e.g.,  a  “data  source”  connects  directly  to  a  “data  sink.”  Thus,  each  connection 

interface  can  be  different  from  one  another.  SPA,  however,  changes  that  paradigm  with 
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its  notion  of  modular  open  systems  architecture  (MOSA).  It  utilizes  a  data-centric  plug- 
and-play  approach  and  introduces  the  concept  of  running  an  integrated  network  for  the 
bus  where  each  subsystem  or  component  has  a  standard  interface  that  can  plug  into  any 
available  port  on  the  network,  similar  to  a  personal  computer  network  running  on 
Ethernet  connection.  Rather  than  the  point-to-point  connections  on  a  traditional 
spacecraft  build,  the  SPA  network  employs  cascade-able  routers  and  standard  protocols 
for  communication  between  components.  This  approach  promotes  the  idea  of  a 
“composable”  system  where  different  pieces  can  be  assembled  into  a  full  system,  similar 
to  a  child’s  building  block  system  (such  as  the  one  popularized  by  LEGO),  where 
building  bricks  are  stacked  together  to  form  an  object.  The  key  factor  here  is  that  the 
components  utilize  standard  interfaces  and  message  formats,  hidden  from  the  physical 
layer  (i.e.,  encapsulated),  and  the  components  can  be  arranged  into  many  configurations. 

In  a  basic  example,  when  a  component  is  plugged  into  the  SPA  network,  it  will 
identify  itself  and  specify  to  the  network  what  telemetry  data  it  will  produce  and  what  it 
will  require.  The  SPA  network  will  then  discover  and  register  the  component  as  a  node 
on  the  network.  The  result  is  a  plug-and-play  network,  comparable  to  a  Universal  Serial 
Bus  (USB)  plug-and-play  device  on  a  computer.  The  analogy  is  illustrated  in  Figure  1. 
Note  that  the  driver  comes  with  the  operating  systems  in  the  computer  model  (or  must  be 
supplied  by  a  user,  following  a  system  “message  box”  prompt),  while  the  spacecraft 
model  uses  an  electronic  datasheet  embedded  on  the  device  itself  in  lieu  of  the  driver. 
This  difference  is  insignificant,  as  Figure  1  shows  only  a  basic  concept  of  how  SPA 
works. 
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"platform" 


USB  interface  chip 


Figure  1.  Plug-and-Play  Analogy  (From  Lyke  &  Peck,  201 1) 

The  real  SPA  network  integration  is  a  bit  more  complex.  Since  all  the  components 
or  subsystems  have  different  functions,  the  data  they  provide  and  receive  are  different.  A 
computer  on  the  network  is  still  a  computer  similar  to  other  computers  on  the  network. 
The  computers  can  talk  to  each  other  because  they  use  the  same  language  and  data 
format.  On  a  spacecraft  bus,  the  components  and/or  subsystems  are  different  from  one 
another.  They  serve  different  purposes  and  thus  may  use  different  languages  and  data 
formats.  A  thermal  sensor  will  provide  temperature  readings  to  the  bus  system  in  degrees 
Celsius,  but  a  magnetometer  will  provide  the  strength  and  direction  of  a  magnetic  field  at 
a  particular  location.  To  integrate  all  the  different  types  of  messages  and  data  formats 
into  a  single  network,  a  form  of  middleware  is  needed.  The  middleware  will  act  as  a  go- 
between  for  the  many  different  “data  sources”  and  “data  sinks”  and  ensure  that  each  “data 
source”  pairs  with  the  right  “data  sink.”  The  SPA  network  architecture  showed  in  Figure 
2  illustrates  the  SPA  Network  description. 
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Figure  2.  SPA  Network  Architecture  (From  Lyke  &  Peck,  2011) 

In  Figure  2,  the  plug-and-play  middleware  overlays  on  top  of  the  network  and 
abstracts  (or  hides)  the  intricacies  of  where  a  component  is  plugged  and  the  details  of  its 
power  consumption,  etc.  A  set  of  applications  (apps)  is  designed  for  this  middleware.  The 
apps  are  connected  through  this  middleware  to  components,  and  sometimes  to  each  other. 
The  middleware  is  in  a  sense  a  unifying  broker.  The  next  section,  SPA  Technology, 
describes  the  composition  of  the  SPA  network. 

3.  SPA  Technology 

SPA  is  a  family  of  standard  interfaces  and  self-describing  and  automatically 
configurable  components  that  create  a  self-organizing  network  connecting  elementary 
“data  sources”  to  the  “data  sinks”  that  depend  on  them  (Lyke  &  Peck,  2011).  As 
illustrated  in  Figure  2,  the  technologies  needed  to  enable  SPA  consist  of  the  software, 
hardware  and  the  network. 

a.  Software 

The  software  includes  the  apps  and  the  SPA  Service  Manager  (SSM)  that 
is  the  middleware.  The  SSM  is  a  collection  of  services,  network/subnetwork  managers 
and  applications  within  the  SPA  (AIAAa,  2011).  It  may  be  the  operating  systems  or  part 
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of  the  operating  systems  on  a  spacecraft.  The  system  developer  can  decide  on  the 
selection  of  the  SPA  compliant  spacecraft-level  software.  The  services  central  to  the  SSM 
are  the  Lookup  Service,  the  Routing  Table,  the  Application  and  Endpoint  Subscriber 
Lists,  and  the  Central  Address  Service  (CAS)  (AIAAa,  2011). 

The  apps  are  software  modules  that  interface  with  the  SSM.  They  may  be 
supporting  applications  such  as  orbit  estimator,  subsystem  controllers  (e.g.,  power 
management)  or  layers,  and  libraries  (e.g.,  the  math  library).  The  apps  may  be  flight 
heritage  codes  that  have  been  modified  to  be  SPA-compliant  or  new  modules  developed 
specifically  for  a  mission.  The  common  key  feature  among  these  apps  is  the  standard 
interface  to  the  SSM.  In  principle,  well-designed  apps  can  be  re-used  and  shared  through 
mechanisms  like  “application  stores.” 

b.  Hardware 

SPA  defines  a  new  approach  for  building  spacecraft.  In  order  to  make 
possible  the  SPA  architecture,  a  few  key  hardware  components  are  needed.  These 
components  are  the  routers,  the  power  hubs,  and  the  Applique  Sensor  Interface  Module 
(ASIM).  As  previously  mentioned,  SPA  brings  the  network  concept  into  the  spacecraft 
bus  architecture.  The  point-to-point  connections  on  the  traditional  spacecraft  do  not 
require  routers.  A  network  such  as  SPA,  however,  requires  a  router  to  manage  the 
message  traffic.  In  addition,  the  various  adjunct  components  utilize  different  voltages  and 
normally  have  electronics  power  controllers  (EPC)  to  convert  the  standard  bus  voltage  to 
the  necessary  component  voltages.  In  light  of  these  voltage  requirements,  SPA  introduced 
a  standard  voltage  for  the  various  components.  The  power  hubs  are  required  to  provide 
the  power  management  and  distribution  for  the  hardware  components.  With  the  standard 
electrical  and  physical  interface,  having  a  power  hub  reduces  the  amount  of  harnesses 
required  for  the  spacecraft. 

The  last  hardware  piece  required  for  the  SPA  network  is  the  ASIM.  The 
ASIM  has  been  a  source  of  contention  among  the  traditional  spacecraft  developers.  Since 
different  spacecraft  components  utilize  different  interfaces  and  message  formats,  the 
ASIM  is  required  to  act  as  a  translator  for  the  legacy  components  to  be  SPA-compliant.  It 
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is  a  small  electronics  module,  typically  containing  a  programmable  microcontroller 
circuit  that  provides  a  logical  and  physical  interface.  As  a  sort  of  legacy  adapter,  it  allows 
a  non-SPA  compliant  device  to  be  able  to  connect  directly  to  a  SPA-based  network 
(AIAAa,  2011).  Early  implementations  of  the  ASIM  concept  were  bulky,  requiring 
implementation  as  an  external  box  between  the  legacy  component  and  the  router.  The 
bulkiness  of  these  prototype  ASIMs  are  unattractive.  They  add  mass  to  the  spacecraft  and 
consume  power;  if  not  otherwise  offset,  they  can  drive  up  costs  when  launching  the 
spacecraft.  However,  factoring  in  the  mass  savings  from  reduction  in  wiring  harnesses, 
and  depending  on  the  size  of  the  spacecraft,  the  additional  mass  growth  is  less  than  a  few 
percent  of  the  overall  spacecraft  mass,  according  to  Comtech  Aero  Astro,  an  aerospace 
company  that  demonstrated  the  SPA  network  in  May  of  2010  (Schenk,  2011). 

The  bulky  ASIM  prototypes  have  been  perhaps  unnecessarily 
controversial.  The  ASIM  was  never  meant  to  be  used  as  a  pennanent,  separate  spaceflight 
component.  The  SPA  developers  envisioned  the  ASIM  as  a  piece  of  software  or  an 
application  specific  integrated  circuit  (ASIC)  embedded  within  the  component  itself  that 
will  make  the  component  natively  SPA-compliant.  This  follows  the  practice  for  USB 
circuitry  in  computer  mice  and  keyboards.  Such  ASIMs  thereby  further  mitigate  any 
disadvantages  of  the  earlier  designs.  At  any  rate,  consistent  with  the  MOSA  philosophy, 
developers  would  be  free  to  implement  the  ASIM-equivalent  functions  in  any  way 
imaginable,  but  the  early  prototypes  served  as  a  convenient  reference  design  for 
experimenters  and  early  adopters. 

Figure  3  depicts  the  role  of  ASIMs  in  a  system  context.  “SPA-S”  refers  to 
components  employing  the  SpaceWire  standard  as  the  native  physical/transport  layer 
(other  physical  layer  designs  studied,  including  Ethernet,  USB,  and  I2C).  “SPA  I/F”  is 
the  SPA  Interface  Board.  “Gen  2  ASIM”  refers  to  the  second  generation  of  ASIMs.  The 
earlier  Gen  1  ASIMs  were  used  in  the  Plug-and-Play  Satellite-One  (PnPSat-1)  during  its 
development.  The  layout  for  PnPSat-2  in  Figure  3  depicts  the  additional  components  of  a 
test  bed  for  plug-and-play  technology  development.  PnPSat-2  is  the  current  reference 
design  for  a  SPA-compliant  spacecraft  (AFRL,  2011). 
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Representative  SPA 


Figure  3.  PnPSat-2  Layout  (From  AFRL,  2011) 


c.  Network 

Defined  as  “an  addressable  and  routable  physically  connected 
infrastructure  composed  of  standard  SPA  transports  for  the  purpose  of  transporting  SPA 
messages  between  SPA  endpoints  and  SPA  gateways,”  the  SPA  network  is  a  byproduct 
of  the  integration  of  the  software  and  hardware  (AAIAa,  2011).  The  network  is  an  entity 
of  its  own,  but  it  is  dependent  on  both  the  software  and  hardware.  However,  it  is  more 
than  just  the  sum  of  both  the  hardware  and  software.  By  turning  the  bus  into  a  robust 
network  of  integrated  components,  which  is  different  from  a  customized  ad  hoc  network 
of  a  typical  spacecraft  bus,  the  network  of  integrated  components  becomes  the  bus 
system.  The  use  of  modular  networks  is  an  important  hallmark  of  the  SPA  concept,  and 
makes  possible  the  composability  and  scalability  of  system  designs  that  employ  it. 
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4. 


SPA  Standards 


SPA’s  success  hinges  on  having  standard  interfaces  for  all  the  components  and 
subsystems.  Thus,  a  set  of  standards  was  generated  by  the  SPA  developers  to  provide 
references  for  constructing  hardware  and  software  capable  of  interfacing  with  a  SPA 
satellite  system.  The  current  set  of  SPA  standards  is  grouped  under  two  categories — 
general  standards  that  apply  to  all  SPA  systems,  and  components  and  application-specific 
standards  that  allow  for  varied  applications  of  SPA  to  support  a  wide  variety  of  needs 
(AIAAa,  2011).  Table  1  lists  the  current  SPA  standards.  Standards  will  change  as  further 
testing  and  development  uncover  issues  that  may  not  be  apparent  at  the  current  stage  of 
SPA  development. 

Table  1 .  List  of  SPA  Standards  (From  AIAAa,  2011) 


SPA  Standards 

Description 

General  SPA  standards 

SPA  System  Capability  Standard 

Correlates  SPA  core  concepts,  SPA  system  services, 
and  the  basic  capabilities  that  are  required  of  a  SPA 
system  to  specific  requirements  derived  directly  from 
SPA  core  concepts. 

SPA  Ontology  Standard 

Revolves  around  the  extensible  Transducer  Electronic 
Data  Sheet  (xTEDs).  Every  hardware  device  or 
software  application  used  within  a  SPA  system  must 
have  an  associated  self-describing  electronic  data 
sheet  that  fully  explains  the  component  to  other 
components  in  the  system. 

SPA  Logical  Interface  Standard 

Describes  the  high  level  capabilities  provided  by 
components  within  a  SPA  network.  Defines  the 
messages,  protocols,  and  interactions  a  standard  SPA 
component  will  use  to  participate  in  the  SPA  network. 

SPA  Networking  Standard 

Defines  normative  requirements  for  networking 
topology  discovery,  routing,  component  registration, 
and  subscription  processing. 

SPA  Timing  Standard 

Establishes  a  common  method  of  synchronizing  time 
across  all  SPA  devices,  processors,  and  applications 
through  the  distribution  of  a  time-at-tone  (TAT) 
message  and  synchronization  pulses. 

SPA  Physical  Interface  Standard 

Details  the  mechanical,  thermal  and  electrical 
connector  interface  requirements  for  SPA  hardware 
components  on  a  SPA-compliant  spacecraft. 
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SPA  Standards 

Description 

SPA  Power  Standard 

Explains  the  means  by  which  power  service  will  be 
supplied  to  SPA  system  components. 

SPA  Test  Bypass  Extension 

Establishes  how  to  implement  optional  test  bypass 
functionality  in  SPA  components  to  support 
component-level  and  integrated  system  test  activities. 

SPA  Application-Specific  Standards 

SPA-S  Subnetwork  Adaptation  Standard 

Specifies  the  required  physical  interface,  with  signal 
characteristics,  for  a  SPA-S  device  based  on  the 
SpaceWire  data  transport  standard. 

SPA-U  Subnetwork  Standard 

Specifies  the  required  physical  interface,  with  signal 
characteristics,  for  a  SPA-U  device  and  the  ASIM 
data  transfer  protocol  developed  for  low-data-rate 
devices  based  on  the  USB  data  transport  standard. 

5.  SPA  Summary 

SPA  introduces  a  new  approach  to  building  spacecraft.  In  contrast  to  the 
traditional  approach  of  point-to-point  connections  between  related  components  on  a 
traditional  spacecraft  with  customized  interfaces  and  protocols,  this  new  approach 
requires  defining  a  new  network-based  architecture  that  standardizes  interfaces  and 
message  formats  among  spacecraft  components  and  subsystems.  To  enable  network- 
based  architecture  and  standard  interfaces  and  message  formats,  new  hardware  and 
software  technologies  and  standards  were  developed.  The  hardware  and  software 
technologies  are  required  to  standardize  and  adapt  legacy  spacecraft  components  to  meet 
the  requirement  of  the  new  architecture.  The  set  of  standards  ensures  compliance  and 
interoperability  of  the  components  within  the  SPA  network. 

B.  TECHNOLOGY  READINESS  LEVELS  AND  OTHER  MATURITY 

ASSESSMENT  METHODOLOGIES 

Technology  maturity  is  related  to  program  risk,  which  affects  performance,  cost, 
and  schedule.  According  to  the  review  of  54  Department  of  Defense  (DoD)  programs  by 
the  U.  S.  Government  Accountability  Office  (GAO)  in  1999,  programs  with  mature 
technologies  averaged  9%  cost  growth  and  a  7-month  schedule  delay,  while  programs 
without  mature  technologies  averaged  41%  cost  growth  and  a  13-month  schedule  delay. 
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Currently,  major  U.  S.  government  acquisition  programs  are  required  to  certify  that  all 
Critical  Technology  Elements  have  been  demonstrated  in  a  relevant  environment  at 
program  initiation  (GAO,  1999).  Thus,  maturity  assessment  has  become  a  critical  part  of 
system  acquisition.  Technology  Readiness  Levels  (TRL)  are  now  discussed. 

1.  Technology  Readiness  Levels 

In  an  environment  of  restricted  resources,  cost  overruns  and  schedule  slips,  the 
TRL  concept  emerged  to  help  system  developers  and  program  managers  gain  control 
over  the  schedule  and  cost  (JBCI,  n.d.).  In  1989,  in  a  paper  titled  “The  NASA 
Technology  Push  towards  Future  Space  Mission  Systems,”  Saden  et  al.  were  the  first  to 
ascribe  the  levels  of  maturity  to  technology  (Moore,  2008).  A  TRL  describes  the  maturity 
of  a  technology  relative  to  its  development  cycle.  Simply,  a  TRL  is  defined  at  a  given 
point  in  time  by  what  has  been  done  and  under  what  conditions  (Moore,  2008). 
According  to  Mankins  (1995),  TRLs  constitute  “a  systematic  metric/measurement  system 
that  supports  assessment  of  the  maturity  of  a  particular  technology  and  the  consistent 
comparison  of  maturity  between  different  types  of  technology.” 

The  first  set  of  TRLs  defines  seven  levels  of  technology  maturity  that  represent 
the  evolution  in  technology  from  initial  concept  to  validation  in  space.  Mankins  (1995) 
then  expanded  the  TRLs  to  nine  levels  with  a  more  complete  set  of  definitions  for  all 
levels.  Until  2002,  the  use  TRLs  was  required  by  DoD  for  contract  initiation,  but 
readiness  level  assignment  was  typically  left  to  the  technology  developer.  There  was  no 
underlying  guidance  or  rigor  for  TRL  assignment;  thus  evaluations  of  technology 
maturity  varied  widely. 

In  2002,  the  Department  of  Defense  (DoD)  was  directed  to  use  NASA’s  TRLs  as 
the  foundation  for  maturity  assessment  and  began  to  develop  a  myriad  of  processes.  DoD 
published  the  first  Technology  Readiness  Assessment  (TRA)  Deskbook  in  2003,  which 
provides  the  user  a  methodological  approach  to  assessing  the  maturity  of  a  technology.  It 
lists  two  different  sets  of  definitions  for  the  TRLs,  one  for  software  and  one  for  hardware. 
The  user  has  to  identify  the  Critical  Technology  Elements  (CTEs)  for  a  system.  These 
CTEs  are  the  critical  elements  the  system  needs  to  meet  operational  requirements  yet  still 
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fall  within  acceptable  production  and  operation  costs  and  schedule.  The  CTEs  can  be  new 
or  modified  and  may  be  software,  hardware,  manufacturing,  or  life  cycle  related  at  the 
subsystem  or  component  level.  The  program  risk  ties  directly  to  the  development  of  the 
CTEs.  Immature  CTEs  increase  risk  to  the  program  cost  and  schedule.  Thus  the  maturity 
of  the  CTEs  is  critical  in  controlling  cost  and  schedule,  and  can  be  determined  by  the 
TRL  process  (DoDb,  2009). 

In  another  initiative,  Congressional  requirements  added  to  the  Fiscal  Year  2006 
authorization  a  set  of  bills  for  NASA  and  DoD  stipulating  that  technologies  required  for 
any  program  be  demonstrated  in  a  relevant  laboratory  or  test  environment.  William  Nolte, 
a  researcher  at  the  Air  Force  Research  Laboratory  (AFRL),  went  a  step  further 
and  developed  the  TRL  calculator  to  automate  the  process.  The  calculator  was  developed 
for  AFRL  internal  use  and  is  only  available  upon  request.  The  calculator  had  been 
modified  to  incorporate  other  features  such  as  tracking  by  project  and  by  Work 
Breakdown  Structure  (WBS)  product,  incorporating  ten  TRL  levels  as  defined  by  the 
NATO  TRL  scale,  and  incorporating  the  AD2  (Advancement  Degree  of  Difficulty) 
process  (JBCI,  n.d.). 

In  addition,  the  concept  of  TRL  began  to  proliferate  to  other  countries  and 
agencies  including  NATO,  European  Space  Agency,  Canada,  the  United  Kingdom,  and 
Japan.  There  is  even  an  international  working  group  attempting  to  develop  a  set  of 
international  TRLs.  Furthermore,  TRL  offshoots  have  emerged,  including  “Design 
Readiness  Levels,”  “Material  Readiness  Levels,”  “Manufacturing  Readiness  Levels,” 
“Integration  Readiness  Levels,”  and  so  on  (JBCI,  n.d.). 

SPA  defines  a  system  of  integrated  network  for  spacecraft.  For  this  thesis,  the 
DoD  Technology  Readiness  Levels  and  Integration  Readiness  Levels  (IRL)  and  System 
Readiness  Levels  (SRL)  developed  by  the  research  team  at  Stevens  Institute  of 
Technology  were  reviewed  (Sausera,  2006).  The  shortfalls  of  these  current  maturity 
assessment  methodologies  are  now  discussed. 
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2.  Shortfalls  of  Current  Maturity  Assessment  Methodologies 

SPA  includes  both  the  technology  and  standards,  complicating  the  simpler 
assessment  approaches  the  TRL  process  provides.  The  Stevens  Institute  of  Technology 
published  a  list  of  shortfalls  found  within  the  TRL  process  (Sauserb,  2006).  Some  of 
those  shortfalls  were  also  identified  by  the  review  of  the  TRL  performed  in  this  thesis. 
They  include  (Sausera,  2006): 

•  TRL  is  only  a  measure  of  an  individual  technology,  and  does  not  assess  its 
maturity  at  the  system  level. 

•  TRL  distorts  many  aspects  of  technology  readiness  into  one  metric. 

•  TRL  cannot  assess  uncertainty  involved  in  maturing  and  integrating  a 
technology  into  a  system. 

The  fact  that  the  TRL  process  only  measures  an  individual  technology  can  be 
construed  from  how  the  TRA  is  performed.  As  described  in  the  TRA  Deskbook,  the  first 
step  in  perfonning  the  assessment  is  identifying  the  CTEs.  The  CTEs  are  elements  of  the 
system  and  not  the  system  itself.  The  TRL  assessment  is  made  for  each  individual  CTE. 
The  definitions  for  the  levels  describe  where  each  CTE  is  in  the  development  cycle, 
whether  it  is  still  a  breadboard  or  has  been  integrated  into  the  system.  The  TRL  process 
thus  measures  only  the  readiness  level  for  individual  technology. 

In  addition,  the  TRL  process  ascribes  a  level  to  the  technology  based  on  where  it 
is  in  the  development  cycle.  For  example,  the  definition  of  TRL  6  is  “system  and/or 
subsystem  model  or  prototyping  demonstration  in  a  relevant  environment.”  Note  that  the 
“system  and/or  subsystem”  in  this  case  does  not  indicate  the  whole  system  being 
assessed.  It  refers  to  the  CTEs  being  integrated  in  a  system  or  subsystem.  The  readiness 
level  ascribed  by  the  TRL  process  is  for  the  whole  CTE — one  single  readiness 
measurement.  It  does  not  take  into  account  the  different  facets  of  the  technology  elements 
such  as  how  well  the  technology  is  integrated  with  the  system  (Sausera,  2006).  If 
integration  of  a  mature  technology  into  an  existing  system  is  difficult  or  challenging,  then 
it  may  not  be  as  readied  as  what  the  TRL  implies. 
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The  technology  readiness  level  also  cannot  be  used  to  detennine  the  uncertainty 
involved  in  maturing  or  integrating  the  technology  into  the  system.  By  definition,  a  TRL 
is  assigned  based  on  a  snapshot  in  the  system  development  cycle.  There  is  no  indication 
of  the  difficulty  in  reaching  that  level  or  going  to  the  next  level.  This  quandary  arises 
because  the  TRL  process  was  purposely  developed  to  help  program  managers  gain 
control  over  program  cost  and  schedule  (JBCI,  n.d.).  Without  knowing  the  uncertainty 
involved,  it  is  difficult  to  detennine  the  risk  to  the  program. 

To  overcome  these  drawbacks,  the  concept  of  System  Readiness  Level  (SRL), 
introduced  by  the  Stevens  Institute,  is  suggested.  The  SRL  is  defined  as  a  function  of  the 
individual  TRL  in  a  system  and  its  subsequent  integration  points  with  other  technologies, 
where  the  measure  of  readiness  for  integration  is  the  IRL  (Sausera,  2006).  The  IRL  has 
seven  levels  and  is  modeled  after  the  TRL.  But  the  IRL  is  different  from  the  TRL  in  that 
it  defines  the  different  level  of  readiness  of  the  integration  of  components  into  the  system. 
The  IRL  is  defined  as  “a  systematic  measurement  of  the  interfacing  of  compatible 
interactions  for  various  technologies  and  the  consistent  comparison  of  the  maturity 
between  integration  points”  (Sausera,  2006).  Basically,  the  IRL  only  assesses  the 
integration  readiness  and  not  the  technology  as  a  whole.  Thus,  the  IRL  cannot  itself 
assess  the  maturity  of  the  technology. 

In  brief,  the  SRL  is  a  function  of  the  individual  TRLs  in  a  system  and  their 
subsequent  integration  readiness  with  other  technologies  as  defined  by  the  IRL.  The 
resulting  interaction  of  the  TRL  and  IRL  is  correlated  to  a  five-level  SRL  index,  which  is 
defined  by  the  state  of  development  corresponding  to  the  DoD’s  Phases  of  Development 
described  in  the  Life  Cycle  Management  Framework  (Sauserb,  2006).  Starting  from  level 
1,  the  SRL  indexes  are:  Concept  Refinement,  Technology  Development,  System 
Development  &  Demonstration,  Production  &  Development,  and  Operations  and 
Support.  A  system  can  be  assigned  an  SRL  based  on  the  resulting  outcome  of  the  TRL 
and  IRL  integration.  As  such,  using  the  SRL  to  assess  the  maturity  of  SPA  seems  to  make 
sense  because  SPA  is  basically  an  integrated  network  of  plug-and-play  software  and 
hardware  components.  But,  by  making  SRL  a  function  of  TRL  and  IRL,  the  SRL  model 
fails  to  provide  an  overall  SPA  system  maturity  assessment  for  these  reasons: 
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1. 


A  system  is  greater  than  the  sum  of  its  parts.  It  is  more  than  just  the  sum  of 
the  components  and  their  interfaces.  SRL  does  not  treat  the  system  as  a 
different,  independent  entity.  For  example,  in  the  case  of  SPA,  all  the 
components  may  have  gone  through  individual  testing  in  a  relevant 
environment  and  achieve  a  certain  TRL  and  IRL.  But  when  they  are 
integrated  into  a  single  system,  the  system  itself  will  have  to  undergo 
testing  in  its  own  “relevant  environment.”  There  are  also  other 
dimensions  that  have  to  be  considered,  such  as,  in  the  case  of  SPA,  the 
reliability  of  the  network  and  the  network  performance,  which  cannot  be 
concluded  from  the  test  results  of  each  individual  component.  Even  if  all 
the  components  are  at  TRL  6  and  at  the  highest  IRL,  it  does  not 
necessarily  mean  that  the  system  also  attains  a  high  SRL. 

2.  SPA  is  an  architecture  with  lots  of  moving  parts,  and  is  not  just  a  single 
point  technology.  The  SPA  standards  are  included  as  part  of  this 
architecture.  The  SPA  standards  are  neither  technologies  nor  processes. 
They  are  documents  that  provide  guidance  for  the  developers.  The 
maturity  of  the  SPA  standards  is  also  critical  to  the  success  of  SPA.  A 
separate  assessment  of  the  maturity  of  the  standards  is  thus  also  required. 

3.  A  key  reason  for  performing  maturity  assessment  of  SPA  is  to  determine 
the  cost  to  reach  a  maturity  level  that  can  be  transitioned  to  industry.  In 
order  to  estimate  the  cost,  “what  else  needs  to  be  done”  must  be  identified. 
There  are  different  activities  that  need  to  be  performed  for  each  individual 
component  and  for  the  system.  Using  the  SRL  would  limit  the  scope  of  the 
assessment  to  the  whole  system.  A  breakdown  of  what  is  needed  to  be 
done  at  the  component  level  would  be  difficult  giving  just  the  SRL  level. 
Assessing  both  the  individual  components  and  the  network  as  a  system 
allows  a  breakdown  of  the  cost  estimation  that  would  provide  a  more 
accurate  overall  estimation. 
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Given  the  analyses  above,  a  new  approach  to  assessing  the  SPA  maturity  is 
needed.  This  new  approach  and  the  actual  maturity  assessment  are  detailed  in  Chapter 
III. 


C.  CHAPTER  SUMMARY 

This  chapter  describes  the  Space  Plug-and-Play  Architecture  and  provides  the 
results  of  a  review  of  the  different  maturity  assessment  methodologies  that  may  be 
relevant  to  SPA.  Information  from  SPA  documentation  supports  the  fact  that  SPA  is  not 
just  a  technology.  It  is  an  integration  of  self-register  and  sclf-con figure  hardware 
components  and  software  modules  that  make  up  the  SPA  network.  The  SPA  components, 
which  include  the  SPA  hardware  and  software,  are  also  discussed  along  with  the  SPA 
standards.  In  addition,  different  maturity  assessment  methodologies  reviewed  discussed 
with  a  primary  focus  on  the  Technology  Readiness  Level. 
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III.  SPA  MATURITY  ASSESSMENT 


A.  APPROACH 

Based  on  the  review  of  the  assessment  methodologies  and  their  alignment  with 
the  SPA  description,  an  assessment  of  SPA  technology  maturity  using  the  Technology 
Readiness  Level  (TRL)  model  is  detennined  to  be  the  best  approach.  As  such,  the  DoD 
Technology  Readiness  Assessment  (TRA)  Deskbook  is  heavily  utilized  to  guide  the 
process.  The  key  point  in  assessing  the  technology  is  to  understand  “what  has  been  done 
and  under  what  condition.” 

Assessing  the  different  software  modules  and  hardware  components  is  a 
straightforward  process  when  one  follows  the  guidelines  in  the  TRA  Deskbook.  The  Spa 
network  consists  of  all  the  components  networked  together  via  software  and  hardware 
interfaces.  The  term  “SPA  network”  is  synonymous  with  the  “SPA  system,”  since  the 
SPA  system  is  the  combination  of  software  and  hardware  components  connect  together. 
For  the  SPA  network,  assessing  its  maturity  is  a  challenge,  since  one  of  the  key  shortfalls 
of  the  TRL  model  is  its  inability  to  assess  the  maturity  of  a  whole  system.  To  get  around 
the  problem,  the  SPA  network  is  assumed  to  be  as  just  another  SPA  technology 
component,  instead  of  the  integration  of  all  the  components.  By  that  assumption,  the  TRL 
process  can  be  used  to  assess  the  maturity  of  the  network. 

However,  one  key  difference  with  the  SPA  network  is  the  fact  that  it  is  not  a 
software  module,  nor  is  it  a  hardware  component.  There  are  different  sets  of  TRL 
definitions  for  hardware  and  software  (DoDb,  2009).  But  the  two  definition  sets  are 
similar,  and  thus  can  be  consolidated  to  use  for  the  network.  There  is  no  variation  in  the 
TRL  levels  for  the  network  using  either  set  of  definition  because  the  activities  and 
environment  for  the  levels  are  the  same  in  both  sets.  However,  different  factors  must  be 
considered  when  doing  an  assessment  on  the  network.  The  network  maturity  assessment 
section  describes  in  detail  the  approach  to  assessing  the  network.. 
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As  for  the  SPA  standards,  there  is  no  formal  published  guidance  on  how  to  assess 
them.  A  new  methodology  for  assessing  the  maturity  of  the  standards  is  needed  and 
developed  and  is  described  in  the  standards  assessment  section. 

B.  ASSUMPTIONS  AND  ASSERTIONS 

Multiple  government  organizations  and  industry  partners  help  to  develop  SPA. 
There  are  varying  approaches,  focuses,  and  degrees  of  success.  Thus,  the  maturity 
assessment  process  requires  certain  assumptions  and  assertions  to  be  made  to  limit  the 
scope  of  the  assessment  to  what  the  government’s  program  office  considers  as  the  main 
effort.  These  assumptions/assertions  are  as  follows: 

1.  SPA  is  currently  being  developed  for  the  satellite  bus.  Thus  only  the 
elements  associated  with  the  bus  will  be  assessed.  The  SPA  reference 
design  (PnPSat-2)  provides  the  basis  for  the  maturity  assessment.  There 
may  be  different  implementations  of  the  SPA  concept  such  as  the  different 
levels  of  modularity.  The  modularity  of  PnPSat-2  is  at  the  component 
level.  Other  developers  have  also  attempted  to  implement  the  SPA  concept 
at  the  subsystem  level.  A  subsystem  usually  consists  of  one  or  more 
components.  To  limit  the  scope,  only  the  technology  being  used  in  the 
reference  design,  which  is  at  the  component  level  of  modularity,  will  be 
assessed. 

2.  SPA  may  evolve  with  different  transport  layer  protocols.  This  maturity 
assessment  is  for  the  current  SPA  implementation,  which  is  SPA-S  using 
the  SpaceWire  transport  protocol. 

3.  Certain  software  functions  are  not  called  out  in  the  SPA  standards.  It  is  left 
to  the  developers  to  decide  how  to  implement  those  functions.  Assessing 
software  maturity  for  contractor-developed  software  will  be  difficult  at 
best  and  therefore  will  not  be  assessed  in  this  thesis.  The  SPA  program 
manager  lists  those  functions  in  the  development  efforts  because  they  are 
necessary  for  further  development  and  testing  of  the  SPA  system.  Some  of 
those  functions  are  (AFRL,  2011): 
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a.  Mission  Infonnation  Service 

b.  File  Management 

c.  Buffer  Management 

d.  Orbit  Estimator 

e.  Attitude  Estimator 

f.  Momentum  Management 

g.  Reaction  Wheel  Torque  Distribution 

h.  Sun  Solution 

i.  Target  Manager 

j.  Telemetry  Manager 

k.  Uplink  Manager 

l.  Downlink  Manager 

4.  The  Plug-n-Play  Satellite  1  (PnPSat-1)  is  an  Engineering  Model  (EM)  to 
have  incorporated  SPA  concept  and  technology.  Although  it  has  not  been 
flown,  it  is  still  a  complete  system  with  integrated  payload.  It  has  gone 
through  rigorous  testing  for  flight,  such  as  a  vibration  test  and  100+  hours 
of  thermal  vacuum  test  (AFRL,  2011). 

5.  Comtech  AeroAstro  (Comtech  AA)  and  Seakr  are  two  of  the  Advanced 
Plug-and-Play  Technology  (APT)  contractors.  Comtech  AA  demonstrated 
a  full  system  utilizing  SPA  architecture  with  integrated  payload.  The 
demonstration  utilized  minimal  numbers  of  real  hardware,  but  mainly  used 
heritage  flight  simulators  with  real  data.  The  Comtech  AA’s  demo 
environment  is  considered  a  “relevant  environment”  for  the  software 
(DoDb,  2009). 
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c. 


IDENTIFYING  CRITICAL  TECHNOLOGY  ELEMENTS 


The  first  step  in  assessing  the  maturity  of  a  system  is  to  identity  the  critical 
components  of  that  system.  The  TRA  Deskbook  was  used  as  a  guide  to  help  identify  the 
Critical  Technology  Elements  (CTEs)  for  SPA  system  (DoDb,  2009).  The  government 
SPA  program  manager  already  had  a  list  of  hardware  and  software  that  are  in 
development.  The  list  was  scrubbed  with  the  SPA  subject  matter  experts  (SMEs)  and 
narrowed  down  to  what  is  critical  to  implement  SPA.  The  SPA  SMEs  include 
government  and  contractor  personnel  who  were  involved  with  developing  SPA 
technologies  and  standards  from  the  beginning  of  the  program.  Table  2  lists  the  CTEs  and 
provides  the  reason  for  their  selection.  Note  that  some  of  the  listed  CTEs  may  not  be 
called  out  in  the  SPA  standards  and  may  be  common  to  the  normal  satellite  build  process. 
But  they  still  can  be  considered  critical  elements  of  SPA  because  either  they  are 
significantly  modified  to  meet  SPA  standards  or  they  are  assumed  to  be  high  risk  with  the 
implementation  of  SPA. 


Table  2. 

SPA  Critical  Technology  Elements 

CTE 

Reason  for  Selection 

Software 

SPA  Service  Manager 
(SSM) 

SSM  is  the  backbone  of  SPA  software.  It  is  to  SPA  as 
Microsoft  Windows  to  a  personal  computer.  SSM  is  the 
updated  version  of  the  Satellite  Data  Model  or  SDM. 
PnPSatl  utilized  SDM. 

SPA  API 

The  SPA  API  provides  a  standard  means  of  accessing  the 
functionality  provided  by  the  SPA  messaging  layer.  It 
facilitates  all  of  the  common  functions  supported  by  the 
SPA  data  functions. 

Layers/Libraries 

Layers  and  libraries  are  a  collection  of  utilities  and 
functions  that  provide  the  interfaces  among  different 
elements  within  the  SPA  system.  Most  layers/libraries  are 
not  new,  but  require  modification  for  implementation 
within  SPA  system. 

Subsystem  Controller 

The  Subsystem  Controllers  are  not  unique  to  SPA.  But 
the  SPA  implementations  of  these  subsystems  differ  from 
the  normal  spacecraft.  They  are  critical  to  the  SPA 
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CTE 

Reason  for  Selection 

approach. 

o  GNC 

The  GNC  Subsystem  Controller  is  the  master  of  all 
applications  and  device  involved  in  GNC/ ADCS 
subsystem  functionality. 

o  Power 

The  Power  Subsystem  Controller  provides  a  system-level 
view  of  the  satellite’s  power.  It  is  responsible  for 
managing  SPA  endpoint  power  and  also  shedding  of 
loads. 

o  Comm  (Contact 
Manager) 

The  Communications  Controller  or  Contact  Manager 
provides  the  ground  user  interface  to  configure  the 
“channels”  that  are  used  by  multiple  users  to  interact  with 
the  satellite. 

Hardware 

SpaceWire  Router 

SPA  requires  a  network  for  implementation.  A  network 
requires  a  router  or  switch  for  robustness  and  flexibility. 
The  router  is  the  center  piece  of  the  network  and  is 
critical  to  SPA. 

Power  Hub 

The  Power  Hub  is  unique  to  SPA  in  that  it  helps  to 
reduce  the  wiring  harness  that  provides  power  to 
components.  It  is  necessary  for  full  SPA  implementation. 

Gen2  ASIM  (include 
analog  Interface  Board) 

The  ASIM  is  the  middleware  interface  between  the  SPA 
network  and  the  spacecraft  components  such  as  Reaction 
Wheel  Assembly  (RWA),  Magnetometer  and  Star 

Tracker.  Normal  spacecraft  components  have  different 
input/output  data.  The  ASIM  enables  the  components  to 
communicate  with  the  SPA  network.  Gen2  ASIM  is  the 
second  generation  of  ASIM.  PnPSatl  used  the  Genl 

ASIM. 

Network 

Network  operation  is  the  byproduct  of  the  integration  of 
the  SPA  software  and  hardware  and  deserved  to  be 
recognized  independently  because  it  is  the  SPA  system 
itself.  The  network  has  to  be  assessed  to  ensure  it  is 
meeting  the  performance  and  that  it  does  not  degrade  the 
functionality  of  the  whole  system  or  any  individual 
component. 
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CTE 

Reason  for  Selection 

SPA  standards 

SPA  standards  will  not  be  assigned  a  TRL.  It  is  a 
standard.  But  it  is  critical  to  SPA  since  the  plug-and-play 
approach  implies  a  common  set  of  standards  for 
components.  The  Standard’s  assessment  will  be  based  on 
industry  or  community  acceptance. 

D.  CURRENT  SPA  TECHNOLOGY  ASSESSMENT 

As  stated  previously,  assessing  the  maturity  of  the  hardware  components  is 
straightforward.  Tests  and  activities  and  the  conditions  that  the  components  have  gone 
through  were  noted.  A  TRL  is  then  assigned  to  a  component  by  comparing  the  noted 
information  with  the  different  TRL  definitions  and  supporting  information.  The  maturity 
assessment  of  SPA  technology  is  broken  down  into  three  separate  categories:  the 
hardware,  the  software,  and  the  network. 

1.  Hardware 

Table  3  lists  the  relevant  TRL  definitions  for  hardware,  excerpted  from  the  TRA 
Deskbook  (DoDb,  2009).  A  technology  component  is  assigned  a  certain  technology 
readiness  level  based  on  what  development  and  tests  it  has  gone  through  and  in  what 
environment.  The  definition  of  each  level  gives  details  on  the  activities  and  environment. 
The  complete  list  of  the  definitions  from  TRL  1  to  TRL  9  can  be  found  in  the  TRA 
Deskbook. 
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Table  3.  Hardware  TRL  Definitions  Excerpt  (After  DoDb,  2009) 


TRL 

Definition 

Description 

Supporting  Information 

4 

Component 

and/or 

breadboard 

validation  in 

laboratory 

environment 

Basic  technological 
components  are  integrated 
to  establish  that  they  will 
work  together.  This  is 
relatively  “low  fidelity” 
compared  with  the 
eventual  system.  Examples 
include  integration  of  “ad 
hoc”  hardware  in  the 
laboratory. 

System  concepts  that  have 
been  considered  and  results 
from  testing  laboratory-scale 
breadboard(s).  References  to 
who  did  this  work  and 
when.  Provide  an  estimate 
of  how  breadboard  hardware 
and  test  results  differ  from 
the  expected  system  goals. 

5 

Component 

and/or 

breadboard 

validation  in 

relevant 

environment 

Fidelity  of  breadboard 
technology  increases 
significantly.  The  basic 
technological  components 
are  integrated  with 
reasonably  realistic 
supporting  elements  so 
they  can  be  tested  in  a 
simulated  environment. 
Examples  include 
“high-fidelity”  laboratory 
integration  of  components. 

Results  from  testing  a 
laboratory  breadboard 
system  are  integrated  with 
other  supporting  elements  in 
a  simulated  operational 
environment.  How  does  the 
“relevant  environment” 
differ  from  the  expected 
operational  environment? 
How  do  the  test  results 
compare  with  expectations? 
What  problems,  if  any,  were 
encountered?  Was  the 
breadboard  system  refined 
to  more  nearly  match  the 
expected  system  goals? 

6 

System  and/or 
subsystem  model 
or  prototyping 
demonstration  in 
a  relevant 
environment 
(ground  or 
space) 

Representative  model  or 
prototype  system,  which  is 
well  beyond  that  of  TRL  5, 
is  tested  in  a  relevant 
environment. 

Represents  a  major  step  up 
in  a  technology’s 
demonstrated  readiness. 
Examples  include  testing  a 
prototype  in  a  high-fidelity 
laboratory  environment  or 
in  a  simulated  operational 
environment. 

Results  from  laboratory 
testing  of  a  prototype  system 
that  is  near  the  desired 
configuration  in  terms  of 
performance,  weight,  and 
volume.  How  did  the  test 
environment  differ  from  the 
operational  environment? 
Who  perfonned  the  tests? 
How  did  the  test  compare 
with  expectations?  What 
problems,  if  any,  were 
encountered?  What 
are/were  the  plans,  options, 
or  actions  to  resolve 
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TRL 

Definition 

Description 

Supporting  Information 

problems  before  moving  to 
the  next  level? 

7 

System 
prototype 
demonstration  in 
an  operational 
environment. 

Prototype  near  or  at 
planned  operational 
system.  Represents  a 
major  step  up  from  TRL  6 
by  requiring  demonstration 
of  an  actual  system 
prototype  in  an  operational 
environment  (e.g.,  in  an 
aircraft,  in  a  vehicle,  or  in 
space). 

Results  from  testing  a 
prototype  system  in  an 
operational  environment. 

Who  perfonned  the  tests? 
How  did  the  test  compare 
with  expectations?  What 
problems,  if  any,  were 
encountered?  What 
are/were  the  plans,  options, 
or  actions  to  resolve 
problems  before  moving  to 
the  next  level? 

8 

Actual  system 
completed  and 
qualified 
through  test  and 
demonstration. 

Technology  has  been 
proven  to  work  in  its  final 
form  and  under  expected 
conditions.  In  almost  all 
cases,  this  TRL  represents 
the  end  of  true  system 
development.  Examples 
include  developmental  test 
and  evaluation  (DT&E)  of 
the  system  in  its  intended 
weapon  system  to 
determine  if  it  meets 
design  specifications. 

Results  of  testing  the  system 
in  its  final  configuration 
under  the  expected  range  of 
environmental  conditions  in 
which  it  will  be  expected  to 
operate.  Assessment  of 
whether  it  will  meet  its 
operational  requirements. 
What  problems,  if  any,  were 
encountered?  What 
are/were  the  plans,  options, 
or  actions  to  resolve 
problems  before  finalizing 
the  design? 

The  TRL  definitions  for  hardware  involve  several  characteristics.  One 
characteristic  is  the  scale  of  the  application,  where  the  component  is  being 
utilized/integrated,  which  ranges  from  device  to  component,  subsystem,  and  system. 
Another  characteristic  is  the  environment,  which  is  perhaps  the  most  difficult 
characteristic  to  interpret  because  it  is  subjected  to  different  types  of  technology  and 
where  it  is  being  used.  Both  TRL  5  and  TRL  6  depend  on  demonstration  in  a  “relevant 
environment.”  The  criterion  for  a  “relevant  environment”  is  as  follows:  “A  relevant 
environment  is  a  set  of  stressing  conditions,  representative  of  the  full  spectrum  of 
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intended  operational  employments,  which  are  applied  to  a  CTE  as  part  of  a  component  or 
system/subsystem  to  identify  whether  any  design  changes  to  support  the  required 
functionality  are  needed”  (DoDb,  2009).  Table  4  displays  the  assessment  of  the  SPA 
hardware  with  supporting  information. 


Table  4.  Hardware  TRLs 


Hardware  CTE 

TRL 

Supporting  Information 

SpaceWire  Router 

5 

The  SpaceWire  Router  in  PnPSat-1  went  through 
thennal  and  vibe  test  for  over  100  hours.  The 
router  used  in  Comtech  AA  has  gone  through 
performance  testing,  but  not  environmental  testing. 
Although  the  router  used  in  the  Comtech  AA  demo 
met  and  exceeded  the  performance  requirement, 
the  router  was  not  radiation-hardened,  which  is 
required  for  operation  in  space.  Another  point  to 
note  also  is  that  there  are  different  flavor  of  routers 
being  used  by  the  contractors.  Seakr  used  a  switch 
that  has  not  been  flown  and  was  considered  an  EM 
at  best,  while  Northrop  Grumman  utilized  a  space 
flight  heritage  router.  The  TRL  assigned  here  is  for 
the  router  used  in  the  PnPSat  reference  design  and 
in  Comtech  AA  demo. 

Power  Hub 

5 

The  Power  Hub  is  in  similar  situation  to  the 
SpaceWire  Router.  Not  all  APT  contractors  use  the 
Power  Hub  in  their  design.  The  assigned  TRL  is 
for  the  Power  Hub  developed  and  built  by 

Goodrich  and  used  in  the  reference  PnPSat  design 
as  well  as  the  one  demoed  by  Comtech  AA. 

Gen2  ASIM  (include 
analog  Interface  Board) 

5 

The  first  generation  ASIMs  were  used  in  PnPSat- 
1.  The  Gen2  ASIMs  were  used  in  the  Comtech  AA 
demo.  Similar  to  the  power  hub  and  router,  the 

Gen2  ASIM  hardware  was  not  radiation-hardened. 
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Hardware  CTE 

TRL 

Supporting  Information 

Overall 

5 

The  overall  score  for  the  hardware  is  based  on  the 
lowest  score  for  the  hardware.  The  hardware 
assessed  here  was  used  in  the  demos,  but  they  did 
not  have  the  required  environmental  protection  for 
used  in  space.  The  demo  environment  for  the 
hardware  was  not  representative  of  the  actual 
operational  environment.  Developers  are  currently 
building  these  component  using  radiation- 
hardened  parts.  The  SPA  hardware  should  be 
assessed  in  term  of  their  functionality  rather  than 
the  hardware  themselves.  For  example,  the  current 
ASIM  added  additional  weight  and  power 
requirement  to  the  system.  Depending  on  industry 
acceptance,  the  ASIM’s  functionality  may  be 
embedded  within  the  component  itself. 

2.  Software 

Table  5  lists  the  excerpt  of  the  software  TRL  definitions  from  the  TRA  Deskbook. 
The  complete  list  of  the  definitions  from  TRL  1  to  TRL  9  can  be  found  in  the  TRA 
Deskbook  (DoDb,  2009). 


Table  5.  Software  TRL  Definitions  Excerpt  (After  DoDb,  2009) 


TRL 

Definition 

Description 

Supporting  Information 

4 

Module 

and/or 

subsystem 

validation  in 

laboratory 

environment 

Basic  software  components 
are  integrated  to  establish 
that  they  will  work 
together.  They  are 
relatively  primitive  with 
regard  to  efficiency  and 
robustness  compared  with 
the  eventual  system. 
Architecture  development 
initiated  to  include 
interoperability,  reliability, 
maintainability, 
extensibility,  scalability, 
and  security  issues. 
Emulation  with  current/ 

Advanced  technology 
development,  stand-alone 
prototype  solving  a 
synthetic  full-scale 
problem,  or  standalone 
prototype  processing  fully 
representative  data  sets. 

32 


TRL 

Definition 

Description 

Supporting  Information 

legacy  elements  as 
appropriate.  Prototypes 
developed  to  demonstrate 
different  aspects  of 
eventual  system. 

5 

Module  and/or 
subsystem 
validation  in 
relevant 
environment 

Level  at  which  software 
technology  is  ready  to  start 
integration  with  existing 
systems.  The  prototype 
implementations  conform 
to  target 

environment/interfaces. 
Experiments  with  realistic 
problems;  simulated 
interfaces  to  existing 
systems.  System  software 
architecture  established. 
Algorithms  run  on  a 
processor(s)  with 
characteristics  expected  in 
the  operational 
environment. 

System  architecture 
diagram  around 
technology  element  with 
critical  perfonnance 
requirements  defined. 
Processor  selection 
analysis, 

Simulation/Stimulation 
(Sim/Stim)  Laboratory 
buildup  plan.  Software 
placed  under 
configuration 
management.  Commercial 
Off-the-Shelf/Govemment 
Off-the-Shelf 
(COTS/GOTS) 
components  in  the  system 
software  architecture  are 
identified. 

6 

Module  and/or 

subsystem 

model  or 

prototyping 

demonstration 

in  a  relevant 

end-to-end 

environment 

(ground  or 

space) 

Level  at  which  the 
engineering  feasibility  of  a 
software  technology  is 
demonstrated.  This  level 
extends  to  laboratory 
prototype  implementations 
on  full-scale  realistic 
problems  in  which  the 
software  technology  is 
partially  integrated  with 
existing  hardware/software 
systems. 

Results  from  laboratory 
testing  of  a  prototype 
package  that  is  near  the 
desired  configuration  in 
terms  of  performance, 
including  physical, 
logical,  data,  and  security 
interfaces.  Comparisons 
between  tested 
environment  and 
operational  environment 
analytically  understood. 
Analysis  and  test 
measurements  quantifying 
contribution  to  system- 
wide  requirements  such  as 
throughput,  scalability, 
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TRL 

Definition 

Description 

Supporting  Information 

and  reliability.  Analysis  of 
human-computer  (user 
environment)  begun. 

7 

System 
prototype 
demonstration 
in  an 

operational, 

high-fidelity 

environment. 

Level  at  which  the  program 
feasibility  of  a  software 
technology  is  demonstrated. 
This  level  extends  to 
operational  environment 
prototype  implementations, 
where  critical  technical  risk 
functionality  is  available 
for  demonstration  and  a  test 
in  which  the  software 
technology  is  well 
integrated  with  operational 
hardware/software  systems. 

Critical  technological 
properties  are  measured 
against  requirements  in  an 
operational  environment. 

8 

Actual  system 
completed  and 
“mission 
qualified” 
through  test  and 
demonstration 
in  an 

operational 
environment 
(ground  or 
space) 

Level  at  which  a  software 
technology  is  fully 
integrated  with  operational 
hardware  and  software 
systems.  Software 
development 

documentation  is  complete. 
All  functionality  tested  in 
simulated  and  operational 
scenarios. 

Published  documentation 
and  product  technology 
refresh  build  schedule. 
Software  resource  reserve 
measured  and  tracked. 

Similar  to  the  hardware  definitions,  the  definitions  of  the  software  TRLs  involve 
several  factors.  At  the  application  level  are  values  of  the  software  module  to  the  system. 
Other  factors  pertaining  to  the  environment  or  application  can  include  integration  issues, 
laboratory  user  environment  issues,  logical  relationship  issues,  data  environment  issues, 
security  environment  issues,  and  possible  interface  issues.  All  these  factors  must  be 
considered  when  assigning  a  TRL  to  each  software  module.  Table  6  depicts  the 
assessment  of  the  SPA  software  technology. 
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Table  6.  Software  TRLs 


Software  CTE 

TRL 

Supporting  Information 

SPA  Service  Manager 
(SSM) 

5 

Comtech  AA  and  Seakr  demonstrated  the  working 
SSM  during  the  Critical  Design  Review.  Although 
there  were  slightly  different  opinions  on  the 
outcome,  all  agreed  that  the  core  functionalities 
are  there.  Comtech  AA  demo  used  heritage  flight 
end-point  simulators  that  use  actual  data  in  the 
complete  systems  to  include  the  payload.  It  is 
rated  a  5  instead  of  a  6  due  to  the  fact  that  there 
were  inconsistent  results  from  the  different 
contractors  conducting  the  demo  and  SSM  is  still 
being  refined  and  troubleshoot.  One  thing  to  note 
also  is  that  the  previous  version  of  SSM,  which 
was  called  Satellite  Data  Model  was  used  on 
PnPSat-1. 

SPA  API 

5 

SPA  API  was  in  the  same  demo  as  the  SSM.  API 
is  still  being  developed  and  tested. 

Layers/Libraries 

6 

The  layers  and  libraries  were  also  involved  in  the 
demos  by  Comtech  AA  and  Seakr.  These  modules 
utilized  heritage  code  with  SPA  modification. 

Subsystem  Controller 

GNC 

6 

The  GNC  module  was  demonstrated  with  PnPSat- 
1  and  by  the  APT  contractors. 

Power 

6 

The  Power  module  was  demonstrated  with 

PnPSat-1  and  by  the  APT  contractors. 

Comm  (Contact 
Manager) 

6 

Comtech  AA  has  this  module  interacting  with 
heritage  ground  systems.  It  was  demonstrated 
with  PnPSat-1  and  by  the  APT  contractors  during 
the  CDR. 

Overall 

5 

Although  the  system  was  demonstrated  in  a 
“relevant  environment,”  the  software  modules  are 
still  being  refined.  There  are  inconsistencies  with 
the  testing  results  from  the  different  contractors. 
Minor  issues  still  crop  up  that  required  resolution. 
The  fault  tolerance  and  security  of  the  software,  in 
general,  have  not  been  fully  implemented. 

3.  Network 

The  SPA  network  is  the  byproduct  of  the  integration  of  software  and  hardware 


components.  The  network  in  this  sense  is  an  entity  of  its  own,  but  is  dependent  on  both 
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the  software  and  hardware.  However,  it  is  more  than  just  the  sum  of  both  the  hardware 
and  software.  Turning  the  spacecraft  bus  into  a  network  of  components,  a  non-traditional 
interpretation  of  a  spacecraft,  implies  that  the  network  is  the  bus  system  itself.  The 
success  of  SPA  depends  on  how  well  this  network  of  component  performs. 

a.  Approach  to  Assessing  Maturity  of  the  Network 

Since  the  network  depends  on  both  the  hardware  and  the  software,  and  the 
definitions  for  the  software  and  hardware  TRLs  are  similar,  the  merged  set  of  definitions 
for  TRL  for  hardware  and  software  is  utilized  with  focus  on  two  factors  to  assess  the 
maturity  of  the  network.  These  two  factors,  performance  and  mission  assurance/fault 
tolerance,  are  pertinent  to  any  network.  For  performance,  the  network  bandwidth  must 
meet  or  exceed  the  total  required  for  the  bus  and  should  not  be  a  hindrance  to  the  overall 
working  of  the  system — insignificant  or  no  delay  in  messaging  traffic.  For  the  mission 
assurance/fault  tolerance,  the  network  must  be  able  to  handle  minor  glitches  and  has 
means  to  correct  itself.  For  example,  if  the  system  fails,  a  command  will  be  sent  to  reboot 
the  system? 

The  motivation  for  this  approach  is  very  simple.  The  network  is  also  part  of  the 
SPA  technology.  Since  the  TRL  model  exists  to  assess  the  maturity  of  the  technology,  it 
would  not  make  sense  to  develop  a  new  method.  When  using  the  TRL  process,  the 
factors  can  vary  from  one  component  to  the  next.  The  key  is  to  identify  the  right  factors 
and  the  environment  for  the  SPA  system. 

b.  SPA  Network  Assessment 

The  SPA  network  perfonnance  was  successfully  shown  during  the 

demonstrations  by  the  Advanced  Plug-and-Play  Technology  (APT)  contractors  (Schenk, 

2011).  “APT”  refers  to  a  body  of  contract  activities  within  the  larger  SPA  technology 

research  programs  at  AFRL.  A  SPA  network  was  demonstrated  on  real  and  simulated 

hardware  and  software  in  a  “relevant  environment.”  Thus,  based  on  the  TRL  definitions, 

the  SPA  network  should  be  at  TRL  5  or  6.  However,  the  network  depends  greatly  on  the 

software  and  hardware.  Misbehavior  of  one  component  has  a  big  impact  on  the  whole 

network.  Such  concern  has  never  been  fully  analyzed  or  evaluated.  In  addition,  even 
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though  the  software  components  are  functioning,  there  are  missing  pieces.  The  software 
has  not  gone  through  an  Independent  Verification  and  Validation  process.  The  security 
and  mission  assurance  parts  of  the  network  have  not  been  thought  through.  As  such,  the 
SPA  network  is  rated  at  a  TRL  4  for  the  following  reasons: 

1 .  Performance  of  the  network  exceeds  the  requirement.  On  average,  the  bus 
subsystem  only  requires  about  1  megabit/second  (Mb/s).  The  SPA 
network  was  demonstrated  at  10  Mb/s  at  Comtech  AA  (Schenk,  2011). 
Spacewire,  which  is  the  basis  of  SPA  networks  on  PnPSat-2,  is  actually 
capable  of  several  hundred  Mb/s. 

2.  The  demonstration  lacks  the  mission  assurance/fault  tolerance  piece.  It  is 
critical  for  network  stability.  Comtech  AA  acknowledged  that  their 
mission  assurance  module,  even  if  it  is  working,  is  rudimentary  at  best 
(Schenk,  2011).  PnPSat-2  developers  have  just  recently  begun  thinking  of 
mission  assurance.  No  methods  for  rigorous  assessment  of  network 
margins  in  terms  of  quality  of  service  have  been  done  in  the  SPA  program 
at  the  time  of  this  work.  Based  on  the  TRL  definitions,  the  successful 
demonstration  of  the  SPA  network  in  a  “relevant  environment”  would  rate 
the  network  at  TRL  5.  However,  the  lack  of  long-term  reliability  data  for 
mission  assurance  reduces  the  rating  to  TRL  4. 

E.  SPA  STANDARDS  ASSESSMENT 

There  is  no  published  guidance  on  how  to  assess  the  maturity  of  SPA  standards. 
The  TRA  Deskbook  is  a  guideline  specifically  created  for  assessing  technology  maturity. 
A  standard  is  not  technology;  it  is  a  description  of  the  effects  or  implementation  of 
technology.  It  is  a  controlled  reference  model  that,  especially  for  composable 
architectures,  permits  a  number  of  independent  groups  to  make  interchangeable  elements. 
A  good  example  of  a  standard  is  the  guideline  for  manufacturing  the  Universal  Serial  Bus 
(USB)  connector.  The  standard  calls  out  the  number  of  pins  and  electrical  currents  and 
voltages  required.  The  dimensions  for  the  connector  are  also  specified.  A  USB  standard 
is  set  so  that  all  components  utilizing  the  USB  port  will  be  physically  and  electrically 
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compatible.  Other  parts  of  the  USB  standard  detail  the  protocols  necessary  to  recognize 
particular  component  classes,  speed  grades,  and  treat  the  nuances  of  power  distribution  in 
a  USB  network. 

1.  Approach  for  the  Development  of  Standard  Maturity  Assessment 

Since  there  is  no  existing  guide  on  how  to  assess  the  maturity  level  for  standards 
under  development,  a  new  methodology  is  defined  in  this  thesis.  This  methodology  in 
essence  follows  the  same  principle  as  the  TRL  process,  which  identifies  the  key 
characteristics  or  dimensions  of  each  technology  component  and  assesses  maturity  based 
on  the  notion  of  “what  was  done  and  under  what  condition.” 

The  main  difference  between  this  methodology  and  the  TRL  process  is  the 
interpretation  of  maturity  level.  The  TRL  process  uses  a  set  of  numbers  to  rate  the 
maturity  of  technology,  whereas  this  methodology  uses  a  set  of  descriptive  words.  The 
reason  for  doing  this  starts  with  the  fact  that  the  SPA  standards  complement  the  SPA 
technology.  While  the  technology  is  the  right  arm  of  SPA,  the  set  of  standards  is  the  left 
ann  of  SPA.  Both  arms  are  needed  to  have  a  successful  SPA.  Additionally,  the  standards 
would  have  to  be  fully  developed  to  be  effective.  The  phase  between  start  development 
and  end  development  is  insignificant;  one  cannot  have  an  incomplete  standard  and  expect 
the  community  to  accept  it.  So,  whether  the  standard  maturity  level  is  a  set  of  numbers  or 
a  set  of  descriptive  words  is  not  as  important  as  having  a  hierarchy  for  completeness. 
Thus,  for  the  standards,  the  maturity  assessment  is  defined  as  follows: 

1.  There  will  be  four  maturity  levels  for  a  standard:  Immature,  Sufficient, 
Mature,  and  Fully  Mature. 

2.  Maturity  level  will  be  assessed  based  in  where  it  is  in  the  development 
cycle,  and  acceptance  by  the  community.  These  are  the  only  two  factors  or 
dimensions  considered. 

3.  The  four  maturity  levels  are  defined  in  Table  7.  A  standard  will  be 
assessed  by  comparing  the  development  progress  to  the  definitions. 
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Standard  Maturity  Level  Descriptions 


Standards  do  evolve.  This  is  true  even  with  solid  legacy  standards  such  as 
Ethernet  and  USB.  Parameters  can  change,  but  they  will  require  user  community 
involvement  and  feedback.  With  that  in  mind,  Table  7  depicts  the  description  of  each 
level. 


Table  7.  Standard  Maturity  Level  Description 


Maturity  Level 

Description 

Supporting  Information 

Immature 

Standard  is  starting  to 
develop.  Established 
standard  configuration 
management  team. 

SMEs  and  various  entities 
working  on  the  technology 
meet  to  discuss 
commonalities  and  standard 
parameters. 

Sufficient 

Standard  is  developed  but 
not  refined.  It  is  being 
implemented  in  the 
laboratory  environment  on 
engineering  model. 

Standard  configuration 
management  team  meets 
regularly  to  resolve  issue. 

Team  establishes  regular 
meeting  to  resolve  issues. 
Draft  copy  of  standard 
available  and  in  review. 

Mature 

Standard  documentation 
completed,  and  standard  is 
implemented  by  a  limited 
number  of  players. 

Standard  is  submitted  to  a 
recognized  entity  such  as 
IEEE  or  AIAA  for 
approval. 

The  standard  is  being 
reviewed  by  the  recognized 
standard  entity.  The 
contractors/ developers 
working  on  the  technology 
produces  product  based  on 
the  agreed  standard. 

Fully  Mature 

Standard  is  approved  by  the 
recognized  entity  such  as 
IEEE  or  AIAA.  Standard  is 
being  widely  used  in  the 
industry. 

Industry  picked  up  on  the 
standard.  The  recognized 
standard  entity  published  the 
approved  standard. 
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2. 


SPA  Standards  Assessment 


The  SPA  standards  provide  the  guidelines  for  building  plug-and-play  spacecraft. 
At  the  time  of  this  writing,  the  SPA  standards  consist  of  nine  different  documents 
detailing  the  electrical  and  interface  standards.  The  SPA  standards  are  rated  “Mature”  for 
the  following  reasons: 

1 .  The  SPA  standards  were  submitted  to  the  American  Institute  of 
Aeronautics  and  Astronautics  (AIAA)  for  approval. 

a.  AIAA  reviewed  the  SPA  standards  and  gave  feedback  to  be 
addressed  by  the  standard  configuration  management. 

b.  Issues  were  expected  to  be  resolved  within  a  few  months  after  the 
SPA  collaboration  review  board  convened.  The  standards  were 
expected  to  be  finalized  and  approved  by  the  end  of  the  calendar 
year  2011.  However,  this  did  not  happen.  According  to  information 
from  the  government  SPA  program  office,  the  SPA  standards  are 
still  in  review  at  AIAA. 

2.  The  three  APT  contractors  were  using  the  standards  during  the  3ld  phase  of 
SPA  development,  where  an  actual  SPA  system  with  real  hardware  and 
software  is  demonstrated.  Northrop-Grumman  is  also  using  the  standards 
to  build  ORS  satellite.  Sierra  Nevada  Corporation  and  Miltec  are  both  on 
board  to  use  the  standards  (AFRL,  2011). 

F.  ASSESSMENT  VALIDATION 

The  readiness  assessment  of  both  the  technology  and  standards  was  briefed  to  the 
SMEs  and  the  government  SPA  program  manager  before  it  was  presented  to  the  SPA 
Collaboration  Review  Board.  At  a  meeting  in  August,  2011,  the  SMEs  and  the  SPA 
program  manager  reviewed  the  methodology  and  concurred  with  the  maturity 
assessment.  Some  contractors  have  rated  the  maturity  of  some  pieces  of  the  technology  at 
higher  TRLs,  an  understandable  point  (Schenk,  2011).  Those  particular  contractors  might 
not  have  any  major  problem  during  integration,  and  only  had  insight  into  a  portion  of  the 
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overall  program.  The  government  program  office  had  the  overall  oversight  and  had 
knowledge  of  problems  encountered  by  other  contractors,  which  were  factored  into  the 
assessment. 

As  reconciliation  for  the  difference  between  the  government’s  and  the 
contractors’  TRL  rating,  it  is  important  to  note  that  the  early  focus  of  plug-and-play 
technology  was  for  small  satellites.  Big  satellites  that  have  a  mission  life  of  10  to 
15  years  would  have  additional  requirements  that  the  smaller  spacecraft  do  not.  The 
Advanced  Plug-and-Play  Technology  contractors  were  focusing  on  developing  the 
technology  for  the  smaller  spacecraft.  The  smaller  satellites  have  shorter  mission  life  and 
long-term  reliability  factor  is  less  critical  when  doing  the  maturity  assessment.  Thus, 
from  the  contractors’  perspective,  the  maturity  rating  of  the  SPA  technology  was  higher. 
In  contrast,  this  assessment  took  into  account  the  needs  of  the  big  satellite,  where  long¬ 
term  reliability  is  a  major  factor.  From  the  government  program  office’s  perspective,  a 
lower  rating  on  the  maturity  level  of  SPA  is  logical  because  the  early  development  of 
SPA  focused  on  meeting  the  need  of  the  smaller  spacecraft  and  not  the  bigger  spacecraft. 

G.  COMBINING  THE  STANDARDS  AND  TECHNOLOGY  MATURITY 

For  the  overall  assessment  of  SPA  maturity,  the  question  remains  on  how  the 
maturity  level  of  the  standards  can  be  combined  with  the  maturity  level  of  the  technology 
to  give  a  one  maturity  assessment  for  SPA.  In  this  thesis,  a  method  to  combine  the 
maturity  level  of  the  technology  and  the  standard  is  provided.  This  method  is  taken  from 
a  method  defined  in  the  Risk  Assessment  process  (DoDa,  2006).  Needless  to  say,  the 
reason  for  the  maturity  assessment  is  to  detennine  the  risk  with  going  ahead  with  the 
program.  So  using  the  Risk  Assessment  process  as  an  analogy  helps  to  facilitate  the 
explanation. 

In  the  Risk  Assessment  process  (DoDa,  2006),  the  risk  levels  (low,  medium,  and 
high)  are  assessed  using  two  dimensions — the  likelihood  of  occurrence  and  the 
consequence  if  it  occurred.  Each  of  these  dimensions  has  five  levels.  So,  based  on  the 
combination  of  the  two,  a  corresponding  risk  level  can  be  assigned.  For  SPA,  a  similar 
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approach  can  be  used  to  combine  the  standards  and  the  technology  maturity.  The  two 
dimensions  of  the  matrix  will  be  the  standards  maturity  and  the  technology  maturity. 
Figure  4  illustrates  the  concept. 

CombiningTwo  Independent  Maturity  Levels 


9 

8 


Immature  Sufficient  Mature  Fully  Mature 
Standards 

Figure  4.  Combining  Two  Independent  Maturity  Levels  Example 

Similar  to  the  Risk  Reporting  Matrix,  the  color  coding  here  would  represent  the 
overall  maturity  levels.  But  the  assigned  colors  are  only  notional  and  not  meant  to 
represent  the  overall  SPA  maturity  assessment.  In  addition,  the  number  of  overall  levels 
is  not  limited  to  three.  The  assigned  levels  based  on  the  combination  of  the  two  are  also 
open  for  interpretation.  For  example,  having  “Mature”  standards  and  a  TRL  5  may  not 
represent  a  medium  level  of  maturity  in  this  case. 

Again,  Figure  4  is  only  used  to  illustrate  a  concept  to  combine  two  dimensions  of 
maturity  assessment.  In  prior  part  of  this  thesis,  the  author  provided  the  methodologies  to 
assess  the  maturity  of  the  SPA  technology  using  existing  DoD  TRL  process  and  the 
maturity  of  the  SPA  standards  using  a  methodology  the  author  developed.  The  author 
then  assessed  the  maturity  of  the  SPA  technology  and  SPA  standards  independently. 
However,  the  primary  reason  for  the  maturity  assessment  of  SPA  was  to  determine  the 
status  and  cost  to  reach  a  transition  phase.  It  was  not  necessary  to  combine  the  SPA 
technology  readiness  level  with  the  SPA  standard  readiness  level  into  a  single  readiness 

level.  But  the  author  did  present  a  method  to  combine  the  two  independent  readiness 
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level  into  a  single  one  based  on  the  Risk  Matrix  process.  More  research  should  be  done  to 
produce  a  set  of  standards  for  combining  independent  readiness  levels  into  a  single  level. 

H.  CHAPTER  SUMMARY 

This  chapter  describes  the  approach  and  assumptions  made  in  order  to  assess  the 
maturity  of  SPA  and  the  result  of  the  assessments.  Table  8  summarizes  the  maturity 
assessment  of  SPA.  Each  TRL  assigned  is  based  on  what  had  been  done  for  each  element 
and  under  what  condition.  The  activity  and  the  environment  each  element  underwent  in 
the  development  process  were  matched  up  with  the  TRL  definitions  to  come  up  with  the 
TRL  level. 


Table  8.  Overall  SPA  Maturity 


CTEs 

TRL 

Software 

SPA  Service  Manager  (SSM) 

5 

SPA  API 

5 

Layers/Libraries 

6 

Subsystem  Controller 

o  GNC 

6 

o  Power 

6 

o  Comm  (Contact  Manager) 

6 

Hardware 

SpaceWire  Router 

5 

Power  Hub 

5 

Gen2  ASIM  (include  analog  Interface  Board) 

5 

Network 

4 

Standard 

Mature 

Overall 

4  (Mature) 
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The  overall  maturity  assessment  of  SPA  technology  is  level  4.  It  is  based  on  the 
CTE  having  the  lowest  maturity  level.  The  standard  approach  in  the  industry  is  to  use  the 
lowest  level,  as  the  system  is  only  as  strong  as  its  weakest  component.  In  this  case,  the 
Standard  is  at  a  level  that  does  not  impact  the  overall  SPA  maturity.  It  is  mature  enough 
to  be  used  and  adopted  by  some  of  the  spacecraft  developers.  The  overall  rating  is 
dragged  down  by  the  network  rating,  which  lacks  the  mission  assurance  piece  necessary 
to  reduce  risk  on  the  overall  system.  The  breakdown  of  the  elements  allows  the  SPA 
program  office  to  identify  different  activities  requiring  action  to  further  mature  them. 
Consequently,  it  will  help  with  the  cost  estimation  to  reach  an  acceptably  mature  SPA  by 
combining  the  estimated  cost  for  each  activity. 
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IV.  CONCLUSIONS 


The  Space  Plug-and-Play  Architecture  (SPA)  introduces  a  new  concept  in 
building  spacecraft.  By  turning  the  traditional  spacecraft  bus  into  a  network  of  plug-and- 
play  components,  it  allows  more  flexibility  and  modularity  at  the  component  level.  SPA 
is  unique  in  that,  to  achieve  full  functionality,  it  requires  mature  components  and  systems 
with  a  fully  mature  set  of  standards  for  industry  to  follow.  This  uniqueness  of  SPA 
creates  a  challenge  for  assessing  its  maturity.  For  this  reason,  to  answer  the  main  question 
of  how  to  assess  the  maturity  of  SPA,  the  SPA  maturity  assessment  was  perfonned  on 
two  different  critical  elements,  the  technology  and  the  standards. 

The  TRA  Deskbook  makes  the  maturity  assessment  of  the  SPA  hardware  and 
software  components  a  straightforward  process.  The  TRL  process,  however,  was  not 
designed  to  assess  the  maturity  level  of  a  system,  and  in  this  case  the  SPA  network  is  a 
system.  But  with  the  system  being  considered  as  another  technology  component,  the  TRL 
process  still  can  be  used  to  assess  the  network.  This  approach  comes  with  a  caveat: 
additional  dimensions  that  are  critical  to  the  network  had  to  be  taken  into  consideration  as 
well.  There  are  sets  of  TRL  definitions  for  hardware  and  software.  But  the  two  sets  are 
very  similar  and  focus  on  “what  was  done  and  under  what  condition.”  Any  one  set  can 
be  used  for  the  network;  even  consolidating  the  two  sets  would  not  change  the  outcome. 
The  two  sets  of  definitions  use  the  same  key  factors  for  the  same  level,  which  are  “event” 
and  “environment.”  Thus,  the  conclusion  is  to  use  the  TRL  process  to  assess  the  maturity 
of  the  network. 

For  the  SPA  standards,  a  different  approach  has  to  be  taken  to  assess  their 
maturity.  There  is  no  published  guidance  for  standards  assessment.  A  standard  is  neither 
a  technology  nor  a  system.  It  is  guidance  on  how  to  do  things  to  meet  certain 
specifications,  a  reference  implementation  that  nails  down  a  specific  set  of  instances  of  a 
broader  technology.  The  traditional  notions  of  TRL  are  not  adequately  suited  for 
assessing  maturity.  But  a  new  methodology  based  on  the  same  principle  can  be  developed 
to  assess  its  maturity.  The  TRL  process  calls  for  dimensions  that  need  to  be  considered  in 

the  evaluation,  and  the  same  assertion  of  “what  was  done  and  under  what  condition”  still 
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applies.  The  process  to  assess  the  maturity  of  standards  is  based  on  these  same  guidelines, 
just  with  a  different  implementation.  Unlike  the  TRL  process,  which  uses  nine  numerical 
levels,  this  process  uses  only  four  “descriptive”  levels  for  the  standards.  The  reason  for 
this  is  because  the  standard  is  not  a  technology. 

The  answer  to  the  second  and  final  question  of  this  thesis  is  the  SPA  maturity 
level  is  4(Mature).  The  outcome  of  the  assessment  is  a  set  of  two  results,  “4”  and 
“mature,”  which  need  to  be  combined  if  the  true  purpose  of  the  assessment  is  to 
determine  the  maturity  level  of  the  architecture.  However,  the  goals  of  assessing  the 
maturity  of  SPA  are  to  determine  the  status  of  each  element  and,  based  on  that  status,  to 
provide  a  cost  estimate  to  further  mature  the  element.  The  goals  are  successfully  achieved 
by  assessing  each  technology  component  separately  and  then  detennining  what  else 
needs  to  be  done  to  reach  the  next  level.  The  overall  system  is  also  assessed  to  determine 
what  else  need  to  be  done  for  the  system  to  reach  the  next  level.  Once  the  required 
additional  activities  are  identified,  the  cost  for  each  activity  is  estimated  using  costs  from 
past  or  similar  efforts. 
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V.  RECOMMENDATIONS 


•  The  TRL  process  provides  the  methodology  for  assessing  the  maturity  of  a 
component,  but  lacks  the  details  on  how  to  assess  the  maturity  of  a  system.  It  is 
recommended  that  DoD  update  the  TRA  Deskbook  (given  its  current  popularity) 
to  include  maturity  assessment  of  technology  at  the  system  level. 

•  The  approach  for  combining  the  two  dimensions  as  described  previously  can  be 
useful  for  future  assessment  of  other  architectures  and  frameworks  involving  a 
mixture  of  technologies  and  standards  bound  to  that  mixture.  Future  research 
should  define  a  standard  set  of  levels  of  maturity  for  the  system  and  develop  an 
approach  to  combine  other  sets  of  maturity  levels. 

•  Finally,  it  is  recommended  that  the  SPA  standards  assessment  process  be  refined 
and  applied  in  future  architectures  of  plug-and-play  spacecraft. 
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